typedef의 세밀한 구분

Search BackLinks only
Display context of search results
Case-sensitive searching

• Linux/필수명령어/용법 . . . . 19 matches
       시간을 지정할 때 상당히 다양한 방법을 사용할 수 있다. hhmm 혹은 hh:mm 형태도 가능하며, noon, midnight이나 오후 4시를 의미하는 teatime이라고도 할 수 있다. 오전 오후를 쉽게 구분하려면 am pm 문자를 추가해도 된다. 이미 지나간 시간이라면 다음 날 그 시간에 수행될 것이다. 정확한 날짜를 지정하려면 mmddyy 혹은 mm/dd/yy 아니면 dd.mm.yy 형태 중 선택하라.
       : 파일에서 필드를 뽑아낸다. 필드는 필드 구분자나 문자 위치로 지정된다.
       - cut -f필드 -d필드 구분자 [ -s ] 파일명(들)
       -d필드 구분자 : 필드를 구분하는 문자를 지정한다. 디폴트는 탭 문자다.
       -s : 필드 구분자를 포함할 수 없다면 그 행은 하지 않는다.
       -i : 대소문자를 구분하지 않는다.
       -i : 대소문자 구분을 하지 않는다.
       -t 문자 : 필드 구분 문자를 정한다. 기본적으로 공백, 탭, 기행 문자다.
       -i : 대소문자를 구분하여 탐색한다.
       - paste [ -s ][ -d구분문자 ] 파일명(들)
       -d구분문자 : 어떠한 문자로 칼럼을 구분하는지 지정한다. 기본값은 탭 문자이다.
       - PID : 프로세서 ID, 각 프로세서를 구분하기 위한 고유의 ID
       원격 파일과 원격 호스트 이름은 콜론을 사용하여 구분한다. 마지막 인수가 디렉토리 이름이라면 지정된 모든 파일들은 그곳으로 복사된다.
       -t 문자 : 단어 등 필드를 구분하는 문자를 지정한다. 탭(tab)이나 공백 문자 이외의 문자를 구분 문자로 취급하도록 한다.
       wc라는 이름은 word counter를 의미하는 것이 아닌가 생각한다. 아무런 옵션을 주지 않고서 사용하면 행수, 단어수, 문자수를 모두 검사해서 보고한다. 텍스트 문서 속에서 단어란 공백(space)문자, 탭(tab)문자 그리고 개행(newline)문자에 의해 구분되는 문자들의 집합을 의미한다.
       -q : 사용자 이름과 카운트가 구분된 목록을 보여줌
• MoreEffectiveC++/Techniques2of3 . . . . 15 matches
       만약 Item 30에 언급되는 proxy 클래스 방법을 사용해서 읽는 작업과, 쓰는 작업에 대한 것을 구분한다면 StringValue 객체의 숫자를 좀더 줄일수 있을 것이다. 그건 다음 장에서 보자.
       다차원 배열과 같은 인스턴스를 만드는 프록시의 사용은 일반적이다. 하지만 프록시 클래스들은 일반 배열보다 유연하지 못하다. Item 5에서 예를 들어 보면 어떻게 프록시 클래스들이 의도하지 않은 생성자의 사용을 막을수 있는지 방법을 보여준다. 하지만 프록시 클래스의 다채로운 사용이 가장 잘알려진 것은 마로 operator[]에서 write와 read를 구분하는 것이다.
       이러한 상태, 즉 perator[]에서 lvalue와 rvalue를 구분해야만 한다. 왜냐하면 참조세기가 적용된 자료구조의 경우에 읽기는 쓰기에 비하여 훨씬 적은 비용을 소모하기 때문이다. Item 29에서 참조세기 객체의 쓰기는 아마 전체 자료구조의 복사를 유도하지만, 읽기는 간단한 값의 반환을 의미한다고 설명했다. 불행히도, operator[]의 내부에서, 이들의 호출 목적을 구분할 방법은 없다. operator[]는 lvalue와 rvalue의 쓰임의 차이를 구분할수 없다.
       "그렇지만 잠시!" 하고 당신이 말한다. "꼭 그럴 필요가 없다. operator[]의 상수화 된 개념을 받아들여서 operator[]의 읽기와 쓰기를 구분하면 되지 않은가?" 이러한 다른 측변으로 당신은 우리에게 문제의 해결 방식을 제안한다.
       불행히도 이러한 것은 수행되지 않는다. 컴파일러는 const와 non-const 멤버 함수의 구분을 오직 그 객체가 const인가의 여부에 따라만 판단한다. 이러한 구현은, const구별의 목적을 위해 아무런 영향을 못 끼친다.
       그러므로 이런 방식의 operator[]의 오버로드는 읽기와 쓰기의 구분에 실패한다.
       Item 29에서 우리는 operator[]를 쓰기를 위해서 재 디자인했다. 아마 이걸 쉽게 포기할수는 없을 꺼다.(작성자주:얼마나 고생하면서 봤는데, 바꾸기 싫지.) Item 29의 디자인은 lvalue와 rvalue의 사용을 구분하는 것이 아니라, operator[]를 호출하면 무조건 쓰기로 취급해 버리는 것이다.
       operator[]가 읽기와 쓰기를 구분 못하지만 일단 우리는 가능한한 이것을 구현해 보고자 하는 입장에서 접근해 보자. operator[]가 반환한 이후에 읽기와 쓰기의 상태를 알아내는 방법을 필요로 한다. 이것의 의미는 앞에 다루었던, lazy evaluation의 개념과 비슷하지 않을까?
       으로 둘은 lvalue와 rvalue를 구분하고 올바르게 사용하게 된다.
       Item 29에 나와있는, non-const String::operator[]과 비교해보면 인상적인 느낌이 올것이다. 이것은 예측할수 있다. Item29에서는 이러한 쓰기와 읽기를 구분하지 못해서 무조건 non-const operator[]를 쓰기로 취급했다. 그리고, CharProxy는 String에 대한 자유로운 접근을 위해 friend로 선언했기에 문자값의 복사 과정의 수행이 가능하다.
       Software Engineer을 수행하는 입장이라면 물론 이와 같이 CharProxy를 통해서 읽기와 쓰기를 구분해서, 복사에 해당하는 코드를 삭제해야 한다.하지만 이것에 대한 결점을 생각해 보자.
       proxy 클래스의 사용은 operator[] 사용시 lvalue와 rvalue의 구분을 명료하게 한다. 그렇지만 무시할수 없는 결점을 가지고 있다. proxy객체는 그들이 목표하는 객체를 완전히 교체하는 것이 목표지만 정말 어렵다. 여기에서 문자처럼, lvalue와 rvalue의 목적뿐 아니라. 다른 방법으로 객체는 접근될수 있다.
       두번째의 결과, CharProxy가 다른점은 lvalue와 rvalue의 구분을 위해 operator[]가 적용된 프록시 클래스를 사용하는, 참조세기 배열 템플릿이라면, 확연히 드러나는 것이다.
• MoreEffectiveC++/Efficiency . . . . 5 matches
        === Distinguishing Read from Writes ( 읽기와 쓰기의 구분 ) ===
       첫번째 operator[]는 문자열을 읽는 부분이다,하지만 두번째 operator[]는 쓰기를 수행하는 기능을 호출하는 부분이다. 여기에서 '''읽기와 쓰기를 구분'''할수 있어야 한다.(distinguish the read all from the write) 왜냐하면 읽기는 refernce-counting 구현 문자열로서 자원(실행시간 역시) 지불 비용이 낮고, 아마 저렇게 스트링의 쓰기는 새로운 복사본을 만들기 위해서 쓰기에 앞서 문자열 값을 조각내어야 하는 작업이 필요할 것이다.
       이런 네가지의 예제는 lazy evaluation이 다양한 영역에서 활용될수 있음을 시사한다.:필요없는 객체의 복제 피하기, operator[]에 읽기와 쓰기를 구분하기, 데이터 베이스 상에서의 필요없는 자료 읽기를 피하기, 필요없는 수치 계산을 피하기. 그럼에도 불구하고 그것은 정말 훌륭한 생각만은 아니다. 단지 해치워야 할일을 미루어서 처리하는 것이기 때문에 만약에 당신의 부모가 계속 감시를 한다면 당신은 계속 그런 일들을 해주어야 한다. 마찬가지로 프로그램 상에서도 모든 연산들이 필요하다면 lazy evaluation은 어떠한 자원의 절약도 되지 않는다. 거기도 만약 당신의 모든 계산이 반드시 필요한 중요한 것들이라면, lazy evaluation은 아마 처음에 허상 데이터들과 의존 관계같은 것의 처리를 위하여, 실제보다 더 많은 연산을 하게되어 수행 속도를 느리게 할것이다. lazy evaluation은 오직 당신의 소프트웨어 상에서 피할수 있는 계산이 존재할 때만 유용히 쓰일수 있다.
       여기 관련 구분이다.
       한걸음 뒤로 물러서서, 우리의 목표는 형변환 이 아닌 operator+를 UPInt와 int구분의 혼합으로 호출할수 있게 만들수 있음을 알수 있다. 암시적 형변환의 문제가 끝났것 같다. 그러면, 혼란스런 의미에 종지부를 찍어 보자. 여기 operator+의 수행을 성공시키는 또 다른 혼합된(mixed-type) 호출 방식이 있다. 그것은 처음 시도한 방법에서 암시적 형변환을 제거해 줄것이다. 만약 우리가 UPInt와 int를 합을 할수 있기를 원한다면 우리는 그걸 전부다 그렇게 그대로 만든다. 몇개의 함수를 각기 다른 인자 형(parameter type)으로 overload해서 선언해 버리는 것이다.
• 영어학습방법론 . . . . 5 matches
        * 우리나라 사람들은 외국 사람과 발음, 청음의 이해차이가 있다. girl을 걸이라고 발음하지 않았고 Law와 Low를 외국사람들은 잘 구분하지만 우리는 별로이다. 이는 계속해서 들어온 발음에서 우리가 계속 구분해서 들어본 발음이 아니므로 우리가 구분하기 쉽지 않다. 따라서 비슷한 발음은 자주 들어서 구분을 할 수 있는 연습이 필요하다.
        즉 자주 쓰는 것으로 경험을 통해 축적해야만 위와같은 비슷한 발음을 의미를 파악해서 구분이 가능하다.
• 창섭/배치파일 . . . . 5 matches
       - /C[:]문자열 : 사용자가 선택할 수 있는 키목록을 [] 괄호 내에 ', ' 로 구분하여 출력하고 /C 스위치를 사용하지 않으면 기본적으로 YN이 사용됩니다.
       - /S : 사용자의 입력에서 소문자, 대문자를 구분하도록 합니다.
       ◇ 설명 : 입력 가능한 키를 a,b,C,D로 한정하며 사용자로부터 입력되는 영문자의 대,소문자를 구분하는데, 만약 5초 내에 사용자로부터 키 입력이 없다면 C 가 입력된 것으로 간주합니다. 그리고 화면에는
       - <집합> : %%<변수>에 대입하고 싶은 값을, 또는 스페이스로 구분하여 대입하고 싶은 순서대로 나열합니다.
       - <문자열1> == <문자열2> : <문자열1> 과 <문자열2> 가 같을 때에만 참이되고 <명령>이 실행됩니다. 주의할 점은 문자열의 대,소문자가 구별되며, 문자열중에 구분기호(콤마,스페이스,세미콜론,등호,탭)가 포함되어 있으면 않됩니다.
• ProgrammingPartyAfterwords . . . . 4 matches
       먼저 ZP#1팀은 Mentor 채희상씨와 함께 요구분석을 시작하였으나 어떤 방법으로 이루어져야 하는지 어떤 형식으로 하여야하는지 서로 명확히 몰랐기 때문에, 아무도 말을 하지 않고 있었다. 희록님이 생각하기에 '이렇게 아무말도 없다면, 시간만 흘러가게 될 것이다. 내가 약간 분위기를 만들어야겠다'는 생각을 했다. 그래서 "자 우리 모두 자기가 생각하는 요구사항을 말해보기로 하자"라고 하였고, 우리는 서로의 요구사항에 대한 논의가 있었다.
       그 때쯤인가, ZP#2팀의 Mentor이신 김창준님이 '슬쩍' 오셔서 Design이 잘 떠오르지 않는다면, 비슷한 아키텍쳐를 가진 문제를 풀어서 그 아키텍쳐를 재사용해 보라는 말씀을 하셨다. 하지만, 우리 팀원중 아무도 그것에 대해선 이후에 언급하지 않았다.(묵살되었다. --) 그러다가 우선 요구분석에 대한 이해를 높이고, 디자인을 상세화하기 위해서(디자인->코딩->디자인->코딩 단계를 반복하였다.) 코딩을 시작하기로 하였다. 상협군과 인수군은 매직펜을 맡았고, 희록군은 키보드를 맡았다. 희록군은 Unix환경에서의 Eclipse의 작업 문제로 인해 심각한 스트레스를 받고 있었다. 그러다가 컴퓨터를 한번 옮겼으나 그 스트레스를 줄이진 못했다. 아무래도 공동으로 프로그래밍 하는거에 익숙하지가 않아서 좀 서투룬 감이 있었다. 그래도 해야 겠다는 생각을 하고 문제의 요구 사항을 분석하고 어떻게 설계를 해야할지 의논했다.
       요구분석을 마치고 디자인을 하기로 한 시간이 되었기에 팀원들은 한 테이블에 모였다. 그리곤 CRC 카드를 이용해서 디자인에 들어가기 시작했다. 암묵적으로 ["구근"]님이 ZP#2의 무게중심이 되어서 디자인 회의가 시작되었다. 어떤 클래스들이 필요한가, 어떤 이벤트를 누가 발생시키고 그 이벤트를 누가 알아야하는가에 대한 이야기가 오가는 가운데 ["데기"]는 문제파악 조차 제대로 안되어서 무척 혼란스러웠다. 서로 요구분석 이해에 차이가 있었음에도 불구하고 디자인은 계속 진행되었고, 시간은 계속 흐르고 흘러서 구현을 시작하기로 한 시간을 훌쩍 넘어버렸다.
• 지금그때/OpeningQuestion . . . . 4 matches
        * 해야 할 일과 하고 싶은 일을 구분
       NoSmok:피터드러커 교수의 [이노베이터의조건]나, TheNextSociery 를 보면, 지식 노동자와 지식 기술자의 정의가 있습니다. 고등학교때 배웠던 정보화 사회는 현재에서 이미 도래했습니다. 그는 책에서 대중적 직업을 크게 지식 기술자와 지식 노동자로 나뉩니다. 지식 기술자는 '''General 한 주제'''을 가지면서 '''한 주제에 특화된 능력'''을 가진 사람이고, 둘다 부족하거나, 한 주제에 전문가 인점을 빼면 지식 노동자로 구분합니다. 정보화 사회의 중기에는 이 두계층의 구분이 거의 없는 반면, 지식 직업들이 늘어나면서 이는 확연히 구분됩니다. 앞으로 더 심해 질것입니다.
• 1002/Journal . . . . 3 matches
       사실 {{{~cpp LoD}}} 관점에서 보면 자기가 만든 객체에는 메세지를 보내도 된다. 하지만 세밀한 테스트를 하려면 좀더 엄격한 룰을 적용해야할 필요를 느끼기도 한다. 니가 말하는 걸 Inversion of Control이라고 한다. 그런데 그렇게 Constructor에 parameter로 계속 전달해 주기를 하다보면 parameter list가 길어지기도 하고, 각 parameter간에 cohesion과 consistency가 떨어지기도 한다. 별 상관없어 보이는 리스트가 되는 것이지.
        * 모르는 단어의 경우 단어의 빈도를 봐서 사전을 찾을때와 나중에 사전을 찾을때를 구분하는것도 좋은 것 같다. 사전을 뒤적거리는데에 일종의 Context Switching 이 일어난다고 할까.
       세미나 자료 준비전 창준이형으로부터 여러 조언들을 들었었다. 'Sub Type 과 Sub Class 에 대한 구분에 대해서 설명했으면 좋겠다', 'OOP 를 하면 왜 좋은지 느낄 수 있도록 세미나를 진행하면 좋겠다', '문제 해결에 대한 사고 과정을 보여줄 수 있으면 좋겠다' 등등. 구구 절절 생각해보면 참 일리있는 이야기들이였다. 개인적으로도 세미나 준비하는 가장 고학번이니 만큼 잘 하고 싶었고.
• BigBang . . . . 3 matches
        * 함수 decorator : C++의 오버로딩을 하게 되면, 컴파일 타임에서 각각의 함수를 구분할 수 있도록 붙는 머릿말
        * #define와 typedef의 차이
        * 위의 각각의 예시는 메모리 기반, node 기반(linked-list)으로 구분이 된다.
• C/C++어려운선언문해석하기 . . . . 3 matches
       [[ typedef의 세밀한 구분 ]]
• HolubOnPatterns/밑줄긋기 . . . . 3 matches
        * 패턴 간의 연관성 의존성 때문에 한 패턴을 다른 패턴과 구분하기 어려울 수도 있다. 이럴 경우에는 정적 구조 대신 패턴의 의도에 초점을 맞추기 바란다.
        * 객체 지향 시스템과 절차 지향 시스템을 구분하는 한가지 좋은 방법은 무언가를 변화시킬 때 어떤일이 발생하는가를 보는 것이다.
        * extends와 implements 간의 유사성은 C++ 언어에서는 명확하다. C++는 이 둘을 구분하지 않기 때문이다.
• ISBN_Barcode_Image_Recognition . . . . 3 matches
        * Center Guard는 Left Characters와 Right Characters를 구분하는 심볼이다.
        * 가운데에 있는 비트 5개(32 가지수)로 숫자를 구분하며, Left(Odd), Left(Even) 중에 겹치는 것이 없다.
        * 모든 인코딩에 대해 0, 1을 영역으로 구분하면 그 영역은 항상 4개이다.
• ProjectCCNA/Chapter5 . . . . 3 matches
        * ip의 생성이유 : TCP/IP프로토콜을 사용하는 모든 장비를 구분하기 위해서
        * ip주소는 네트워크 부분과 호스트 부분으로 구분.
        * /표시는 network부분과 host부분을 구분한 것.
• ProjectVirush/Idea . . . . 3 matches
        4. 백혈구는 각 인간의 고유한 DNA의 일부를 통해서 적, 아 를 구분한다. (J)
        9. 백혈구의 떨어지는 DNA는 아군 세포를 구분하지 못하여 공격할 수 있다. (F, E)
        -그냥 방법이라고 했잖냐 ㅋ 각각 바이러스를 유저마다 고유특성을 가지게 만들어서 그 고유특성에따른 암호를 나타내서 DNA흉내를 내는거라고 ㅋ 유전자 길이를 길게하고 상동유전자를 만들어서 우열의 법칙을 적용시키는것도 재미있겠지 ? +_+ 암수를 구분한건 생각으로적용시킨 유전자가 환경에 얼마나 적응 할수있을까? 해서 만들어 본거다 ㅋ 한번 창발적 세계를 만들어 보아요 >.<)b - [정수민]
• Spring/탐험스터디/wiki만들기 . . . . 3 matches
        * 다른 행위(page content view, page history view)를 하지만 더 큰 행위(page view)의 subset이므로 Request주소는 같게 하고 parameter를 달리해 두 행위를 구분하려 했다.
        * RequestMappingHandlerMapping의 매핑 테이블을 보니 {[ URL ], methods=[ Method 타입 ], params=[],headers=[],consumes=[],produces=[],custom=[]}등으로 Request를 구분하고 있었다.
        * RequestMapping의 method 타입을 이용해 signup 페이지 호출과 실제 signup을 구분하여 핸들링
• ViImproved/설명서 . . . . 3 matches
       B 한 공백 구분 단어 뒤로 이동 U 현재 줄의 변화를 취소
       ^c 삽입모드 끝냄(명령어 x) W 한공백 구분 단어 오른쪽으로
       E 한 공백 구분 단어 끝으로 이동 Y 현재줄을 yank
• ZeroPage_200_OK/note . . . . 3 matches
        * 강의 노트는 날짜나 요일 별로 구분하지 않고 큰 주제별로 분리할 생각입니다. 그렇게 하는 편이 나중에 찾아보기에 좋을것 같습니다 -[안혁준]
        * 할당된이름과 관계없이 구분할수 있다
        * 자바스크립트는 함수와 일반 변수와의 구분이 없기때문에 변수 또한 dispatch가 된다.
• 정모/2003.3.5 . . . . 3 matches
        * 상욱이의 의견에 찬성합니다. 그러나 학회 활동을 지나치게 위키에만 의존하는 것은 경계해야 할것 같습니다. 그리고 준회원과 정회원 구분이 어떤 의미를 갖는지, 꼭 필요한 구분인지 궁금합니다. --["이덕준"]
        * 정회원과 준회원의 큰 차이는 없다고 생각합니다. 다만 우리 서버의 계정을 받는 문제나 행사 자체를 끌고 가는 인력을 뽑는 것 등 진행적, 실질적 문제가 조금의 차이를 보이기 때문에 구분을 하는 것으로 생각합니다. -- 상욱(["whiteblue"])
• 프로그램내에서의주석 . . . . 3 matches
       내가 Comment 와 JavaDoc 둘을 비슷한 대상으로 두고 쓴게 잘못인듯 하다. 두개는 좀 구분할 필요가 있을 것 같다는 생각이 들어서다. 내부 코드 알고리즘 진행을 설명하기 위해서는 다는 주석을 comment로, 해당 구성 클래스들의 interface를 서술하는것을 JavaDoc으로 구분하려나. 이 경우라면 JavaDoc 과 Class Diagram 이 거의 비슷한 역할을 하겠지. (Class Diagram 이 그냥 Conceptual Model 정도라면 또 이야기가 달라지겠지만)
        그리고, JDK 와 Application 의 소스는 그 성격이 다르다고 생각해서. JDK 의 소스 분석이란 JDK의 클래스들을 읽고 그 interface를 적극적으로 이용하기 위해 하는 것이기에 JavaDoc 의 위력은 절대적이다. 하지만, Application 의 소스 분석이라 한다면 실질적인 implementation 을 볼것이라 생각하거든. 어떤 것이 'Information' 이냐에 대해서 바라보는 관점의 차이가 있겠지. 해당 메소드가 library처럼 느껴질때는 해당 코드가 일종의 아키텍쳐적인 부분이 될 때가 아닐까. 즉, Server/Client 에서의 Socket Connection 부분이라던지, DB 에서의 DB Connection 을 얻어오는 부분은 다른 코드들이 쌓아 올라가는게 기반이 되는 부분이니까. Application 영역이 되는 부분과 library 영역이 되는 부분이 구분되려면 또 쉽진 않겠지만.
• 2학기파이선스터디/함수 . . . . 2 matches
       lambda 콤마로 구분된 인수들: 식
       || 구분 || def로 정의되는 함수 || lambda 함수 ||
• Bigtable/DataModel . . . . 2 matches
        1. SSTABLE의 주소와 오프셋으로 블록들이 구분된다.
        1. 명시적인 자료구조가 아니라 SSTable에서 row key들로 구분되어진 범위이다.
• CCNA . . . . 2 matches
        * ip의 생성이유 : TCP/IP프로토콜을 사용하는 모든 장비를 구분하기 위해서
        * ip주소는 네트워크 부분과 호스트 부분으로 구분.
• CVS . . . . 2 matches
       현재 ZeroPage 의 경우 CVSROOT 는 /home/CVS 이므로 viewcvs.conf 의 경우 다음과 같이 설정되어있다. (여기서 Development 는 일종의 이름. 여러개의 root 존재시에는 ','로 구분한다.
       [도구분류]
• EuclidProblem . . . . 2 matches
       한 줄에 두 개씩의 수가 입력되며 두 수는 각각 A와 B다. A와 B는 스페이스로 구분된다. (A, B < 1,000,000,001).
       입력된 각 줄에 대해 각각 스페이스로 구분된 세 개의 정수 X와 Y 그리고 D를 출력한다. 식을 만족하는 X와 Y가 여러 개 있으면, (첫째로) |X| + |Y|가 최소가 되고 (둘째로) X <= Y 인 값을 출력한다.
• GarbageCollection . . . . 2 matches
       가비지 컬렉션의 주요 기술은 다음의 2가지로 구분할 수 있다.
       2번째의 것의 경우에는 자료구조 시간에 들은 바로는 전체 메모리 영역을 2개의 영역으로 구분(used, unused). 메모리를 할당하는 개념이 아니라 unused 영역에서 빌려오고, 사용이 끝나면 다시 unused 영역으로 돌려주는 식으로 만든다고함. ㅡㅡ;; 내가 생각하기에는 이건 OS(or VM), 나 컴파일러 수준(혹은 allocation 관련 라이브러리 수준)에서 지원하지 않으면 안되는 것 같음. 정확하게 아시는 분은 덧붙임좀..;;;
• ImmediateDecodability . . . . 2 matches
       파일에서 연속된 데이터를 그룹 형태로 입력을 받아들인다. 그룹의 각 데이터는 기호용 이진 코드를 나타내는 0과 1의 집합으로 구성된다. 각 그룹은 단일 숫자 9로 구분된다. 구분 숫자인 9는 그룹에 속하지 않는다.
• KnowledgeManagement . . . . 2 matches
        * 무언의 지식을 구분하는 대중적인 방법은 그것이 우리의 두뇌에 있는지 여부이고, 명시적인 지식을 구분하는 방법은 우리가 그것을 체계화 한 지식인지 여부이다.
• LexAndYacc . . . . 2 matches
        * 이번은 동사만 구분하는식으로 하겠습니다
       ["도구분류"]
• MFC/CObject . . . . 2 matches
       이 클래스로부터 파생된 클래스는 다음의 3가지 레벨로 구분되는 기능이 있다.
       각 레벨의 구분은 다음의 매크로를 통해서 설정할 수 있다.
• MoreEffectiveC++/Exception . . . . 2 matches
        catch (invalid_argument & ex){ // 이 문은 작동을 하지 않는다. 위의 catch구분에서 이미 잡아 버린다.
       자, 먼저 pointer(by pointer)에 관한 전달을 생각해 보자. 이론적으로 이 방법은 throw위치에서 catch구분으로 예외를 특별한 변화 없이 느린 프로그램 수행 상태에서 전달하기에 가장 좋은 방법이다. 그 이유는 포인터의 전달은 해당 예외 객체가 복사되는 일없이 포인터 값만 전달되는 방법만을 취해야 하기 때문이다. 말이 좀 이상한데 예외를 보면서 설명한다.
• MoreEffectiveC++/Miscellany . . . . 2 matches
       그 목표는 유용한 추상화와 추상화를 추상 클래스로 존재하게 강제해 버리 도록 구분한다. 그렇지만 당신은 어떻게 유용한 추상화를 분간 할것인가? 누가 그 추상화가 미래에도 유용한지 알려주는가? 누가 어디로 부터 상속되는지 예상할수 있는가?
       동적 메모리 할당(dynamic memory allocation:이하 동적 메모리 할당)에 관한 문제가 우리에게 주어진다. 일반적인 규칙은 간단하다.:C++ 에서 new, delete 부분 (Item 8참고) 그리고 C 프로그래밍 에서는 malloc(그리고 그것의 변수들) 과 free이다. malloc으로 얻은건 free로, new로 얻은건 delete로 해재하는한 모든 것이 올바르다. 그렇지만, new로 할당된 메모리 영역을 가리키는 포인터를 free로 해제 시키는 호출은 예측 못하는 수행을 가지고 온다. 마찬가지로 malloc로 얻은 것을 delete로 해제하는 것도 예측할수 없다. 그렇다면, 이를 기억하기 위한 방법은 new와 delete, malloc와 free를 엄격하게 구분해야 하는 것이다.
• MoreEffectiveC++/Operator . . . . 2 matches
       이 구분에서 '''> > ''' 이 두개를 붙여쓰면 '''>>''' operator로 해석하니 유의해라
        * Item 6: prefix와 postfix로의 증감 연산자 구분하라!
• VMWare . . . . 2 matches
       유사기술을 적용한 Linux [Xen] 커널이 등장하기 시작했으며, Xen 은 차후 나타나게될 멀티코어 CPU 환경(플랫폼 자체가 완전히 다른)에 적합한 커널의 구축을 목표로 하고 있다고 한다. (완전히 다른 프로세서라면 당연히 해당 머신에 접근하는 인터페이스 역시도 다를텐데 XEN 을 이용해 해당 부분을 추상화시켜서 접근하는 식으로..) 현재에는 해당 기술을 보안 분야에서 이용하기 위한 연구가 진행중이며 기존의 단일 커널하의 커널모드, 유저모드 식의 구분이 아닌 관리자 커널, 애플리케이션 커널과 같은 구분으로 2개의 서로 다른 커널을 구현해 커널 단에서 애플리케이션이 머신에게 직접적으로 접근할 가능성을 원천 차단하는 방식의 연구가 되고 있다.
• ZeroWiki/제안 . . . . 2 matches
       지금 이 페이지처럼 오래된 내용이 남아있는 페이지를 어떻게 해야할지 논의해보고 싶습니다. 대부분의 페이지에서는 오래된 내용이 쌓여 좋을 때가 많지만 이 페이지 같은 경우 위키에 대한 제안과 논의가 이루어지는 페이지인데 이미 과거에 해결된 제안과 그에 대한 논의를 기록을 남겨놓는 것이 좋은 것인지 잘 모르겠습니다. 그냥 그대로 놔두면 현재 제안과 구분하기 쉽지 않으니까요. 제가 생각하는 선택지는 네가지 입니다.
        내가 ZeroWiki 글을 처음 썼었을때가 좀 예전이긴 하지. 그때는 주로 페이지를 생산해내는 중심체들이 프로젝트 그룹이였고 (지금도 그렇지만, 예전에 비해 개개인들의 독립된 활동들이 많아졌지.) 일단 사람들 스스로가 학습용도나 개인훈련기록용으로 잘 이용하는 것 같고. 그래서 특별히 그에 대해 구분하고 싶은 생각은 없는중임. (단, 개인페이지내에서의 진행기록들이 너무 많아지는 것 같아서. 계층 위키에 대해서 개인적으로 조금 경계하는중.) 의견있으면 계속.~ --["1002"]
• pragma . . . . 2 matches
       C 와 C++ 을 구현한 각각의 컴파일러에는 포팅된 하드웨어나 OS 에 의존적인 몇몇가지들의 기능을 가지고 있다. 일례로 몇몇의 프로그램들은 메모리에 데이터가 어떠한 방식으로 자리잡을 것인지 에 관한 문제나 함수가 파라미터들을 조작하는 방법들에 대한 세밀한 조작이 요구된다. #pragma 지시어들은 C 와 C++ 언어 안에서 최소한의 호환성을 유지시키며 그러한 시스템 의존적인 명령어들을 언어의 기능으로서 포함시키는 일을 한다. Pragma 지시어들은 일반적으로 '''컴파일러들 마다 서로 다르다'''.
       [도구분류]
• 데블스캠프2002/진행상황 . . . . 2 matches
       꼭 생소하다의 문제를 떠나서, 전반적인 컴퓨터 동작원리 보다 구체적 용어들 (어떻게 보면, 이미 공부하여 알고 있는 사람들의 경우 일상어화 되어버린 언어들)이 먼저 나와버렸기 때문이다. 컴퓨터가 하드웨어와 소프트웨어로 구분되어지기 이전엔 어떠했는지, 그게 하드웨어와 소프트웨어로서 구분하는 방법으로서 폰 노이만 아키텍쳐가 나온 이야기라던지, 그러하기 때문에 PC 카운터가 필요하며 메모리로부터 명령어를 읽어온 뒤, CPU에서 명령을 해석하고 처리한다라던지 등등. 그러한 이야기가 나오기전에 어드레스/세그먼트/옵셋/디코딩 이 나와버렸기 때문에 어려운 세미나가 되어버렸다고 생각한다. 후에 상민이가 다시 동작원리부터 상대적으로 쉬운 용어로 설명을 해주면서 사람들의 반응을 유도한점에 대해서는 사람들이 한번 생각을 해볼 필요가 있다. 우리와 대화하는 사람은 어느정도의 지식수준을 가지고 있는가에 대해서. 정말 이해 안가는 부분에 대해서는 질문 자체를 만들어내기 힘들다. --석천
• 데블스캠프2005/주제 . . . . 2 matches
       시간에 여유가 있으면 이런 시간을 마련해 보는것도 좋을 듯 합니다. 일종의 '토의'인데요. 신입생, 재학생 (여름방학정도 되면 신입생, 재학생을 구분하는 의미가 축소되기는 하지만 여기서 표면적으로나마 준비하는 사람들-참가하는 사람들을 구분해서 표현할만한 마땅한 표현이 없으므로 패쓰)들이 그동안 경험해 왔던 '프로그래밍 공부'에 대한 이야기를 나눠보는 것입니다. 이러한 이야기를 나눠봄으로써 참가자들간에 많은 피드백이 이루어질 것이고, 이러한 경험들은 앞으로 공부를 하는데 있어서나 프로그래밍을 하는데 있어서 소중한 양분이 될 것입니다.
• 문자반대출력/허아영 . . . . 2 matches
        영어와 한글을 구분하는 것은 구했는데,
        비베에서는 한글이나 일본어처럼 2바이트를 사용하는 글자의 경우 알아서-_- 판단하고 한 글자 단위로 읽는 함수가 있긴 한데 씨에서는 알파벳과 같은 1바이트 문자인지 아니면 2바이트 문자인지를 어떻게 구분해야 할까요? -태훈 [zyint]
• 상협/삽질일지/2002 . . . . 2 matches
        * 이 에러는 까먹기 전에 적어 놓아야 겠다는 생각이 들어서 여기에 적어야 겠다. 오늘 내가 만든 클래스를 인클루드 할때 난 대소문자 구분안해도 되는줄 알았는데 구분 안하니깐 링크할때 에러 떳다. 이 에러가 왜 나오는건줄 몰라서 겁나게 삽질 했었는데.. ㅡㅡ;
• 새싹교실/2012/AClass/4회차 . . . . 2 matches
       -원형 큐로 기본 큐와 마찬가지로 첫 번째 데이터가 추가되는 순간 큐의 처음과 끝부분이 그 데이터를 가리키게 된다. 처음을 F 끝부분을 가리키는 것을 R이라하면 꽉찬 경우나 텅빈경우에 F가 R의 한칸 앞을 가리키는 것은 같기 때문에 F,R의 위치만을 가지고 꽉 찬경우와 텅 빈 경우를 구분할 수 가 없다. 따라서 이와 같은 문제를 해결하는 방법은 많겠지만 그 중 하나는 배열을 꽉 채우지 않고 배열의 길이가 N이라면 N-1만큼만 채워 졌을 때 꽉 찬 것으로 간주하는 방법이다. 이렇게 하면 저장 공간 하나를 낭비하게 된다. 하지만 이로 인해서 문제 하나가 해결이 되는 셈이다.
        - 원형으로 이루어져 있기 때문에 큐가 가득 찼을때나 완전히 비어있을때 Front와 Rear의 index는 동일하므로 Empty인지 Full인지 구분할 수 없다.
• 새싹교실/2012/개차반 . . . . 2 matches
        * 변수의 이름은 대소문자를 구분한다
        * 수를 이진법으로 표현 시 양수/음수를 구분하기 위해 사용되는 맨 앞자리 0을 수를 표현하는 데에 사용하여 두 배 많은 수를 표현
• 시간관리인생관리/요약 . . . . 2 matches
        1. 삶에서 추구하는 다짐과 활동의 분야들을 목록으로 작성하라. 공사를 포함하고 가능한 잘게 나누어서 모든 분야를 구분하라.
        ==== 사업의 '현재'를 위해 일하는 것과 사업의 '미래'를 위해 일하는 것을 구분하라. ====
• 아인슈타인 . . . . 2 matches
       현대의 상대성 이론등 그의 업적을 아는 사람들은 그가 무척이나 복잡한 사람을 꺼라 생각할 것이다. 하지만 그는 세수하는 비누와 면도하는 비누의 구분을 귀찮아 할만큼 단순함을 좋아했다.
       아인슈타인은 국가주의를 공격했고 평화주의 사상을 장려했다. 베를린에서 반유대주의 물결이 거세어지자, 아인슈타인은 '물리학에서의 볼셰비키주의자' 범주로 구분되었고, 그가 시오니즘 운동을 대중적으로 지지하기 시작하자 우익집단들의 그에 대한 격노가 거세졌다. 아인슈타인은 베를린에서 적대를 받았으나 유럽의 다른 도시에서 그에게 요청한 것 때문에 상대성이론을 강의하러 유럽의 여러 도시들을 널리 다녔는데, 보통 3등열차를 타고다녔고 늘 바이올린을 지니고 있었다. (from http://preview.britannica.co.kr/spotlights/nobel/list/B14a2262b.html)
• 위키QnA . . . . 2 matches
        * 반대로 Semi Project의 Regular Project로의 선택은 막습니다. 이것이 허용되면 구분의 의미가 없겠죠?
        * Regular Project와 Semi Project를 나눈 원래의 취지는 개인이나 2명의 극히 소수가 진행하고 있는 작은 규모와 3명 이상의 단체가 진행하는 일이라고 생각했습니다. 하지만 받아 들이는 입장에서는 다른 의도로 받아 들이지 말아 주세요. 혹은 둘을 구분하는 다른 효과적인 기준을 제시해 주세요.
• 위키의특징 . . . . 2 matches
       || 게시물의 구분 || 일련번호 || 페이지 이름 ||
       || '''구분''' || '''MindMap''' || '''[위키위키]''' || '''KMS''' || '''[블로그]''' ||
• 작은자바이야기 . . . . 2 matches
        * abstract factory패턴과 factory method 패턴의 구분
        * 명령어의 prefix로 타입을 구분한다. http://en.wikipedia.org/wiki/Java_bytecode#Instructions
• 정모/2004.5.7 . . . . 2 matches
        - 회원 구분의 명확치 않다
        - 회원 구분 기준을 낮추었으면 좋겠다
• 02_C++세미나 . . . . 1 match
       하나는 &이고, 다른 하나는 *이다.(여기서 *는 포인터를 만들때의 *와는 다른 의미이므로 잘 구분하기 바란다.)
• 1002/TPOCP . . . . 1 match
        * 장르구분?
• 1thPCinCAUCSE/null전략 . . . . 1 match
       도구는 연습장과 인덱스 카드, assert 문을 이용한 테스트 케이스 등을 이용했습니다. 연습장과 인덱스 카드는 주로 개개인 수식과 중요 변수들을 적기 위해, 또는 그림을 그리기 위해 이용했고 (두 도구의 용도가 구분되어있진 않았음) 문제에 대해서 답이 나왔다하는 가정하에 (문제지에 Sample Input->Output 이 나와있었기에 가능했습니다.) Backward 로 문제가 해결된 상황을 가정하고, 그러기 위해 필요한 변수들을 찾아나가는 방법으로 진행했습니다. 프로그래밍 스타일은 Structured 스타일의 Stepwise Refinement & PBI & assert 를 이용한 TDD 를 사용했습니다.
• <시작페이지 사용규칙> . . . . 1 match
        * 시작페이지에서 메뉴와 링크에는 링크명 양끝에 "<", ">" 를 넣어 다른 페이지들과 구분한다
• AcceleratedC++/Chapter11 . . . . 1 match
        C++은 = 가 객체의 초기화, 복사 시에 동일하게 사용되기 때문에 복사 생성자와, 대입연산자의 구분이 없다.
• AcceleratedC++/Chapter6 . . . . 1 match
        1. 모든 학생의 레코드를 읽어들여, 모든 과제를 제출한 학생들과 그렇지 않은 학생들을 구분합니다.(6.2.1)
• AcceleratedC++/Chapter7 . . . . 1 match
       || '''Key''' || 요소의 검색을 위해서 사용되는 검색어. 한개의 요소를 다른 요소와 구분하는 역할을 한다. 키는 요소의 변경시에 변경되지 않는 값이다. 이에 반하여 vector의 인덱스는 요소의 제거와 추가시 인덱스가 변화한다. 참조)DB의 WikiPedia:Primary_key 를 알아보자. ||
• Ant . . . . 1 match
       ["도구분류"]
• AntiSpyware . . . . 1 match
       [도구분류]
• Apache . . . . 1 match
       [도구분류]
• AustralianVoting . . . . 1 match
       각 테스트 케이스에 대해 당선된 후보의 이름 한 줄, 또는 동률을 이룬 후보들의 이름이 들어있는 여러 줄을 출력한다. 두 개 이상의 테스트 케이스가 있는 경우 각 결과는 빈 줄로 구분한다.
• Basic알고리즘/팰린드롬/허아영 . . . . 1 match
       한글인지 아닌지 판단해서, 구분하는 것도 만들어 볼 생각이다.,
• Boost . . . . 1 match
       ["도구분류"]
• BoostLibrary . . . . 1 match
       ["도구분류"]
• CCNA/2013스터디 . . . . 1 match
        * MAC 하위 계층: 맥 주소를 통해 개별 시스템을 구분해 데이터 전송을 제어
• CNight2011/고한종 . . . . 1 match
       몰라 이거 구분은 종하형이 말한 그 라운드가 아니라 그냥 내가 생각하는 라운드임ㅇㄹㅇㄹㅇㄹ
• CToAssembly . . . . 1 match
       이는 하드웨어만을 고려한 것이다. 모든 마이크로컴퓨터 시스템은 하드웨어 구성요소들의 작업을 지시할 소프트웨어가 필요하다. 컴퓨터 소프트웨어는 시스템측(시스템 소프트웨어)과 사용자측(사용자 소프트웨어)으로 구분할 수 있다.
• ChocolateChipCookies . . . . 1 match
       첫째 줄에는 테스트 케이스의 개수를 나타내는 양의 정수가 한 개 입력된다. 그 다음 줄은 빈 줄이며, 서로 다른 테스트 케이스는 빈 줄로 구분된다.
• ClearType . . . . 1 match
       [도구분류]
• ContestScoreBoard . . . . 1 match
       각 테스트 케이스에 대해 앞에서 설명한 순서에 의해 정렬된 점수표가 출력된다. 출력되는 각 줄에는 참가 팀 번호, 그 팀이 푼 문제 개수, 누적된 시간 벌점이 출력된다. 모든 경시 대회 참가 팀이 풀이를 제출하는 것이 아니므로 실제로 풀이를 제출한 팀의 결과만 표시한다. 그리고 두 개의 서로 다른 케이스에 대한 출력은 빈 줄로 구분한다.
• CooperativeLinux . . . . 1 match
       [도구분류]
• CrcCard . . . . 1 match
       ["도구분류"]
• CryptKicker2 . . . . 1 match
       첫번째 줄에는 양의 정수 하나만 들어있는데, 이 정수는 테스트 케이스의 개수를 나타낸다. 그 다음 줄은 빈 줄이다. 서로 다른 테스트 케이스는 빈 줄로 구분된다.
• DPSCChapter2 . . . . 1 match
       우리의 이야기는 지친표정을 지으며 제인의 cubicle (음.. 사무실에서의 파티클로 구분된 곳 정도인듯. a small room that is made by separating off part of a larger room)로 가는 Don 과 함께 시작한다. 제인은 자신의 cubicle에서 조용히 타이핑하며 앉아있다.
• DataCommunicationSummaryProject/Chapter8 . . . . 1 match
        * 전화 번호랑 연계하여서 핸드폰을 구분하기 위해서 사용되는 고유의 번호를 가지고 있다.
• DependencyWalker . . . . 1 match
       [도구분류]
• DevCpp . . . . 1 match
       [도구분류]
• DevCppInstallationGuide . . . . 1 match
       [도구분류]
• Direct3D . . . . 1 match
       [도구분류]
• DirectDraw . . . . 1 match
       ["프로젝트분류"], ["도구분류"] 정도 인가?
• Doublets . . . . 1 match
       입력은 사전과 몇 쌍의 단어로 이루어져있다. 사전은 몇 개의 단어로 구성되는데 한 줄에 한 단어씩 들어가며 사전이 끝나면 빈 줄이 한 개 입력된다. 그 다음 줄부터는 각 줄마다 한 쌍씩의 단어가 입력되며 한 줄에 있는 두 단어는 스페이스에 의해 구분된다.
• DrPython . . . . 1 match
       [도구분류]
• Eclipse . . . . 1 match
       [도구분류]
• EclipsePlugin . . . . 1 match
       [도구분류], [Eclipse]
• EmbeddedC++ . . . . 1 match
       [도구분류]
• EmbeddedSystem . . . . 1 match
       도구분류
• Eric3 . . . . 1 match
       [도구분류]
• ExtremeProgramming . . . . 1 match
       초기 Customer 요구분석시에는 UserStory를 작성한다. UserStory는 추후 Test Scenario를 생각하여 AcceptanceTest 부분을 작성하는데 이용한다. UserStory는 개발자들에 의해서 해당 기간 (Story-Point)을 예측(estimate) 하게 되는데, estimate가 명확하지 않을 경우에는 명확하지 않은 부분에 대해서 SpikeSolution 을 해본뒤 estimate을 하게 된다. UserStory는 다시 Wiki:EngineeringTask 로 나누어지고, Wiki:EngineeringTask 부분에 대한 estimate를 거친뒤 Task-Point를 할당한다. 해당 Point 의 기준은 deadline 의 기준이 아닌, programminer's ideal day (즉, 아무런 방해를 받지 않는 상태에서 프로그래머가 최적의 효율을 진행한다고 했을 경우의 기준) 으로 계산한다.
• FactorialFactors . . . . 1 match
       입력은 여러개의 테스트 케이스로 이루어지며 각 케이스마다 다른 줄로 구분한다. 입력의 끝은 EOF이다. 각 라인은 하나의 정수 n을 가지며, n의 범위는 2 <= n <= 1000000 이다.
• FileZilla . . . . 1 match
       [도구분류]
• FocusOnFundamentals . . . . 1 match
       자바를 후벼파는 것은 좋습니다. 그러나 동시에 OOP도 후벼파야 합니다 -- 사실 OOP를 후벼파면서 자바를 등한시 하기는 어려울 것입니다. 하지만 자바'''만''' 후벼파는 것은 다시 한번 생각해 보십시오(그러나 제가 앞서 말했듯이 잠자다가도 자바 때문에 가슴이 뛴다면 공부하십시오). 미리 배움에 한계를 긋지 마십시오. 그리고 좀 추상적인 이야기가 될지도 모르겠는데, 우리는 "소크라테스가 죽는다"는 것을 배우는 것에서 그치길 원하지 않습니다. 우리는 "사람은 죽는다"는 것을 배우고 싶어합니다. 그러나 그 배움은 직접적인 사실의 체험 이후에 가능합니다. 고로 모든 공부는 기본적으로 귀납을 바탕으로 합니다(이것이 제가 말하는 "몸 공부"입니다). 귀납식, 연역식 공부라고, 또 그것을 개성이라고 구분하는 것은 무의미합니다. see also NoSmok:최한기''''''의 추측록
• FreeMind . . . . 1 match
       [도구분류]
• GIMP . . . . 1 match
       [컴퓨터분류], [도구분류]
• Garbage collector for C and C++ . . . . 1 match
       ["도구분류"]
• Gof/Composite . . . . 1 match
       하지만, 이러한 접근방법에는 문제점이 있다. 비록 대부분의 시간동안 사용자가 개개의 객체들을 동일하게 취급한다 하더라도, 이러한 클래스들을 이용하는 코드는 반드시 기본객체와 컨테이너 객체를 다르게 취급하여 코딩해야 한다는 점이다. 이러한 객체들의 구별은 어플리케이션을 복잡하게 만든다. CompositePattern은 객체들에 대한 재귀적 조합 방법을 서술함으로서, 클라이언트들로 하여금 이러한 구분을 할 필요가 없도록 해준다.
• Gof/Facade . . . . 1 match
       ET++ application framework [WGM88] 에서, application은 run-time 상에서 application의 객체들을 살필 수 수 있는 built-in browsing tools를 가지고 있다.이러한 browsing tools는 "ProgrammingEnvironment'라 불리는 facade class를 가진 구분된 서브시스템에 구현되어있다. 이 facade는 browser에 접근 하기 위한 InspectObject나 InspectClass같은 operation을 정의한다.
• Gof/Strategy . . . . 1 match
        * 많은 관련 클래스들이 오직 그들의 행동들에 의해 구분된다. Strategy들은 많은 행위중에 한가지로 상황에 따라 클래스을 설정해주는 방법을 제공해준다.
• HardcoreCppStudy/첫숙제/ValueVsReference/변준원 . . . . 1 match
       정의,선언,호출이 엄격히 구분되며 Compiler에 의해 처리되어 object file을 만들며 분할 Pro
• HelpOnMacros . . . . 1 match
        * 이경우 대소문자 구분이 중요한데, 반드시 `plugin/파일이름.php`에 대응하는 파일이름을 {{{"각주"=>"매크로파일이름"}}}식으로 지정해야 합니다.
• HelpOnProcessingInstructions . . . . 1 match
       모니위키 페이지를 처리할 때에 프로세싱 인스트럭션 (PI)에 의해 그 기능이 제어될 수 있습니다. 프로세싱 인스트럭션은 페이지의 맨 상단에 위치하며, "{{{#}}}" 문자로 시작하는 키워드(대소문자 구분없음)로 구성되며 인자가 선택적으로 붙을 수 있습니다. {{{##}}} 두개가 시작되는 줄은 주석줄로 처리됩니다.
• HostFile . . . . 1 match
       host 화일을 이용하면, 아직 해당 도메인 이름이 DNS Server에서 셋팅이 이루어지지 않았어도 도메인으로 해당 웹페이지 접근이 가능하다. 웹 프로그래밍을 할때 virtual host 로 서브 사이트들 구분하며 개발시 편리.
• HowBigIsIt? . . . . 1 match
       첫째 줄에는 테스트 케이스의 개수를 나타내는 양의 십진수 n(n≤50)이 입력된다. 그 밑으로 n줄에 걸쳐서 일련의 수들이 입력되는데, 각 수는 스페이스로 구분된다. 각 줄의 첫째 줄은 8 이하의 양의 정수 m이며, 그 줄에 몇 개의 수가 더 들어있는지를 나타낸다. 그 뒤로 m 개의 수가 입력되는데, 각각 상자에 집어넣어야 할 원의 반지름을 의미한다. 이 수들은 꼭 정수가 아니어도 된다.
• HowManyZerosAndDigits . . . . 1 match
       입력에 대해서 주어진 진수 체계에서 팩토리얼 수의 0의 개수와 숫자의 개수를 한 줄씩 출력한다. 두 숫자 사이에는 공백으로 구분한다. 0의 개수와 숫자의 개수가 2^31-1보다 크지는 못할 것이다.
• IDE/VisualStudio . . . . 1 match
       [도구분류]
• ISAPI . . . . 1 match
       ["도구분류"]
• InnoSetup . . . . 1 match
       [도구분류]
• IntegratedDevelopmentEnvironment . . . . 1 match
       [도구분류]
• IntelliJ . . . . 1 match
       ["도구분류"]
• JCreator . . . . 1 match
       ["Java"],["도구분류"]
• JMSN . . . . 1 match
       [도구분류]
• Jakarta . . . . 1 match
       ["도구분류"]
• Java Study2003/첫번째과제/방선희 . . . . 1 match
        * 하드웨어 환경에 따른 구분 : JSEE(Enterprise Edition), J2SE(Standard Edition), M2ME(Micro Edition)
• Java/ModeSelectionPerformanceTest . . . . 1 match
        2. switch - case 로 mode 구분.
• Java2MicroEdition . . . . 1 match
       ["도구분류"]
• JavaScript/2011년스터디/3월이전 . . . . 1 match
        * 문자나 숫자, ""사이에 들어가 것들을 '리터럴'이라고 부르며 따로 구분한다.
• JavaStudy2004/이용재 . . . . 1 match
       함수명이나 변수명을 지을 때 mynameis같이 쓰면 나중에 보거나 딴 사람이 보았을 때 이해하기가 힘들 수 있으니 myNameIs나 my_name_is처럼 각 단어끼리 구분 짓는 습관을 갖는 것이 좋다고 생각합니다. --[강희경]
• Komodo . . . . 1 match
       ["도구분류"]
• Linux/RegularExpression . . . . 1 match
        * -i(option) : 대소문자 구분을 안한다. 예)egrep -i '^(From|Subject|Date): ' mailbox
• MFC/CollectionClass . . . . 1 match
       MFC에서 제공하는 컬렉션을 다루는 클래스는 그 형태에 따라서 크게 3가지로 구분할 수 있다.
• MFC/Control . . . . 1 match
       MFC의 컨트롤들은 대부분 6가지의 종류로 구분된다.
• MacromediaFlash . . . . 1 match
       [도구분류]
• MedusaCppStudy/희경 . . . . 1 match
        cout << "숫자를 차례대로 입력해주세요(숫자는 서로 띄어쓰기로 구분한다) :" << endl;
• MicrosoftFoundationClasses . . . . 1 match
       응용프로그램에서 document를 몇개를 다루느냐에 따라서 SDI(single document interface), MDI(multiple document interface)로 구분하여 사용한다.
• MineFinder . . . . 1 match
       [영현] 형 신기해~ ㅎㅎㅎ bitmap data로 숫자들과 거시기들을 구분한건가..ㅡㅡa.. spy 좋구만..[[BR]]
• ModelingSimulationClass_Exam2006_1 . . . . 1 match
       운전 면허 시험을 본다. 운전 면허 시험은 총 2단계로 구분되어 치러진다.
• MoniWikiOptions . . . . 1 match
        메뉴의 구분자를 설정한다. 기본값은 `'|'` (''deprecated'')
• MoniWikiTutorial . . . . 1 match
       단락의 구분이 모호할 경우는 "----"를 써서 <hr>을 넣을 수 도 있습니다.
• MoreEffectiveC++ . . . . 1 match
        * Item 6: Distinguish between prefix and postfix forms of increment and decrement operators. - prefix와 postfix로의 증감 연산자 구분하라!
• MoreEffectiveC++/C++이 어렵다? . . . . 1 match
        * 다른 언어 : Java는 공통의 플랫폼 차원([http://java.sun.com/j2se/1.3/docs/guide/serialization/ Serialization]), C#은 .NET Specification에서 명시된 attribute 이용, 직렬화 인자 구분, 역시 플랫폼에서 지원
• MultiplyingByRotation . . . . 1 match
       입력은 텍스트파일이다. 진수,첫번째 숫자의 마지막 숫자(the least significant digit of the first factor)와 두번째 숫자(second factor)로 구성된 3개의 수치가 한줄씩 입력된다. 각 수치는 공백으로 구분된다. 두번째 숫자는 해당 진수보다 적은 숫자이다. 입력파일은 EOF로 끝난다.
• MySQL . . . . 1 match
       ["도구분류"]
• NS2 . . . . 1 match
       [컴퓨터분류], [도구분류]
• NUnit . . . . 1 match
       ["도구분류"]
• NamedPipe . . . . 1 match
       ["용어분류"],["도구분류"]
• NetBeans . . . . 1 match
       [도구분류]
• NoSmokMoinMoinVsMoinMoin . . . . 1 match
       || 계층 위키 || 지원 || 지원 (1차 레벨) || '/' 구분자 이용시 부모 페이지 이름 자동으로 붙여줌.(단, 계층 위키의 적절한 이용에 대해선 NoSmok:HierarchicalWiki 의 글 참조||
• NumericalExpressionOnComputer . . . . 1 match
        컴퓨터 언어에서 사용하는 수치표현은 크게보아서 2진수, 8진수, 10진수, 16진수 이렇게 4가지로 구분함. 전류 시그널을 이용하는 컴퓨터의 특성상 2진수의 사용은 필수적인 것이고, 8진수를 사용하는 이유는 과거 12bit, 36bit와 같이 3의 배수 bit를 기반으로한 컴퓨터 archi가 존재했기 때문이다. (현재에서는 거의 쓰이지 않지만, 아직 C/C++ 등 많은 언어에서 제공한다.) 10진수는 인간이 사고하기 편하기 때문에 의미가 있는수. 16진수는 2진수의 표현을 바로 바꿀 수 잇다는 장점으로 표현공간의 절약을 위해서 만이 사용한다.
• OpenGL스터디_실습 코드 . . . . 1 match
       == 외곽선 내곽선을 구분짓는 상태적용 및 별 드로윙 ==
• OurMajorLangIsCAndCPlusPlus/locale.h . . . . 1 match
       #define LC_MONETARY (integer constant expression) 금액 표현(천단위 구분 문자, 소수점 문자, 금액 표시 문자, 그 위치 등)을 위한 로케일 설정
• PairProgramming토론 . . . . 1 match
       pair-implementation과 pair-design, analysis에 대해서는 원래 논문을 꼼꼼히 다시 읽어보길 바랍니다. 특히 각각이 구체적으로 무엇을 지칭하는가를 주의깊게 읽어주길 바랍니다. 또, XP에서처럼, 만약 세가지가 잘 구분이 되지 않고 별도의 design/analysis 세션이 없고, 코딩하는 자리에서 이 세가지가 동시에 벌어진다면 어떻게 될지 생각해 보세요.
• PolynomialCoefficients . . . . 1 match
       여러 쌍의 줄이 입력된다. 각 쌍의 첫번째 줄에는 두 개의 정수 n과 k가 있으며, 그 두 정수는 스페이스로 구분된다. (0<k, n<13) 이 두 정수는 다항식의 승수(다항식을 곱하는 횟수)와 변수의 개수를 나타낸다. 각 쌍의 두번째 줄에는 k개의 음이 아닌 정수 n₁,...,nk가 입력되는데, 이때 n₁+...+ nk = n이다.
• PragmaticVersionControlWithCVS/CommonCVSCommands . . . . 1 match
        * 유닉스, 윈도우의 줄 구분문자를 구별한다.
• PrivateHomepageMaking . . . . 1 match
       내가 돌아본 사이트 들은 대략 3가지 정도의 부류로 구분할 수 있었다.
• ProcessExplorer . . . . 1 match
       [도구분류]
• ProjectPrometheus/EngineeringTask . . . . 1 match
       || UI 작성 + Controller Service 등록 (고려 : 서평은 일반 방명록 스타일. 페이지 구분은 일단 없음) ||
• ProjectPrometheus/Journey . . . . 1 match
        * UserStory 와 Scenario 일부러 혼용해서 썼다. 실제로 우리는 둘다 이용했다고 생각하기 때문에 특별히 구분할 생각을 안했음 --상민
• ProjectPrometheus/LibraryCgiAnalysis . . . . 1 match
        사용자 정보 ( 필수 사항 구분 )
• ProjectZephyrus/PacketForm . . . . 1 match
       이 문서에서 구분자는 # 이다.
• ProjectZephyrus/ServerJourney . . . . 1 match
        * mm.mysql과 Junit 의 라이브러리를 프로젝트 내부에 넣고, 패키지를 network, information, command 로 구분 --상민
• PyDev . . . . 1 match
       [도구분류]
• PythonForStatement . . . . 1 match
       C/Java1.4이하 와 Python의 for문에 대한 관점이 '''전혀''' 다릅니다. 그리고 유용하지요. C의 for문과 구분하기 위하여 python의 이러한 for문을 보통 '''for each''' 문이라고 부릅니다. 이게 진짜 for문 이라고 이야기들 하지요.
• RandomWalk2 . . . . 1 match
       첫 번 째 줄은 바퀴가 총 움직인 횟수(처음 바퀴가 놓이는 것은 움직인 것으로 치지 않는다)이고 한 줄은 띈 다음, 판의 각 칸에 바퀴가 방문한 횟수를 행렬로 출력하되, 동일 행의 칸은 빈칸(스페이스)로 구분하고, 각 행은 하나의 줄을 차지한다.
• RefactoringDiscussion . . . . 1 match
       ps. 현실에서 정말 모든 상태 공간/기계가 고대로 유지되는 리팩토링은 없습니다. 가장 대표적인 Extract a Method 조차도 모든 경우에 동일한 행동 유지를 보장할 수는 없습니다. 1+2가 2+1과 같지 않다고 말할 수 있습니다. 하지만 우리에게 의미있는 정도 내에서 충분히 서로 같다고 말할 수도 있습니다 -- 물론 필요에 따라 양자를 구분할 수도 있어야겠지만, 산수 답안 채점시에 1+2, 2+1 중 어느 것에 점수를 줄 지 고민할 필요는 없겠죠.
• RoboCode . . . . 1 match
       ["도구분류"], ["문제분류"]
• RubyLanguage/InputOutput . . . . 1 match
        * each_line : 세퍼레이터를 넘겨 한 단위(세퍼레이터로 구분)씩 읽어옴
• STL . . . . 1 match
       ["도구분류"]
• SearchAndReplaceTool . . . . 1 match
       [도구분류]
• SeminarHowToProgramItAfterwords . . . . 1 match
        * 흥미로운 것은 시끄러운 프로그래밍이였다는 것이였습니다. 혼자서 하는 프로그래밍(PairProgramming을 알고나니 새로운 개념이 생기는군요. 원래 Programming이라는 것은 혼자하는 거였는데, 이제 프로그래밍하면 pair인지 single인지 구분을 해주어야겠군요)을 하는 경우에는 팀원들이 소란스럽게 떠들면 ''아 지금 설계하고 있구나''하고 생각하고, 조용해지면 ''아 지금 코딩하고 있구나..''하는 생각이 들었는데, PP는 끝까지 시끄럽게 하는거라는 느낌이 들더군요. 그렇게 대화가 많아지는 것은 코딩에 대한 이해도의 증가와 서로간의 협력 등 많은 상승효과를 가져올 수 있다는 생각을 했습니다.
• SimpleDirectmediaLayer . . . . 1 match
       ["도구분류"]
• StacksOfFlapjacks . . . . 1 match
       입력은 여러 개의 팬 케이크 스택으로 구성된다. 각 스택은 한 개에서 서른 개 사이의 팬 케이크로 구성되며 각 팬 케이크의 지름은 1 이상 100이하의 정수로 주어진다. 입력은 파일 끝 문자에 의해 종료된다. 각 스택은 한 줄에 입력되며 맨 위에 있는 팬 케이크가 맨 앞에, 맨 밑에 있는 팬 케이크가 맨 뒤에 입력되고 모든 팬 케이크는 스페이스에 의해 구분된다.
• StandardWidgetToolkit . . . . 1 match
       [도구분류]
• SubVersion . . . . 1 match
       [도구분류]
• TheWarOfGenesis2R/ToDo . . . . 1 match
        * (V) 게임루틴과 출력루틴의 클래스 구분
• TugOfWar . . . . 1 match
       두 개의 서로 다른 케이스에 대한 결과는 빈 줄로 구분한다.
• TwistingTheTriad . . . . 1 match
        근데, WEB 에서의 MVC 와 GUI 에서의 MVC 는 그 Control Flow 가 다르긴 할것이다. 웹에서는 View 부분에서 이벤트가 발생하여 이것이 도로 Model 로 올라간다..식이 없기 때문이다. 믿을만한 출처일지는 모르겠지만, 암튼 이를 구분하는 글도 있는듯. http://www.purpletech.com/articles/mvc/mvc-and-beyond.html
• UML/CaseTool . . . . 1 match
       UML Case 툴의 기능은 크게 다음의 3가지로 구분할 수 있다. round-trip 기능은 최근의 case tools의 발전중에 나오는 기능임. 필수적인 기능으로 보이지는 않음.
• Unicode . . . . 1 match
       유니코드 종류가 많기 때문에 앞에 이런 헤더를 붙여서 구분하기도 합니다.
• UnitTestFramework . . . . 1 match
       ["도구분류"]
• UpdateWindow . . . . 1 match
       [도구분류]
• Vaccine . . . . 1 match
       [도구분류], [투표분류]
• ViImproved . . . . 1 match
       ["도구분류"]
• VisualAssist . . . . 1 match
       ["도구분류"]
• VisualSourceSafe . . . . 1 match
       ["도구분류"]
• VisualStudio . . . . 1 match
       [[include(틀:IDE)]] [도구분류]
• VisualStuioDotNetHotKey . . . . 1 match
       [도구분류]
• VoiceChat . . . . 1 match
       [도구분류]
• WebLogicSetup . . . . 1 match
       ["도구분류"]
• WikiSandPage . . . . 1 match
        * 로그인 여부를 어떻게 구분할 것인가?
• WinSock . . . . 1 match
       ["도구분류"]
• XPlanner . . . . 1 match
       [도구분류]
• Yggdrasil/가속된씨플플/2장 . . . . 1 match
        * 단락평가(short-circuit): 그러니까 if(a==0||b==0){...}에서 왼쪽의 a==0이면 b==0인지는 보지도 않고 괄호 안을 실행한다는 뜻. 자바에선 ||기호와 |기호를 구분하던 것 같았다. 아마 전자는 전부 평가, 후자는 단락평가였던 것 같다.
• ZPHomePage/20050111 . . . . 1 match
        * 제로페이지회원과 일반회원(외부인)을 어떻게 구분할것인가?
• html5/offline-web-application . . . . 1 match
        * 각 항목은 줄 바꿈으로 구분된다.
• html5/outline . . . . 1 match
        * 문서 내 특정 내용을 의미론적으로 구분 짓는 새로운 element들
• iText . . . . 1 match
       [도구분류], [프로그래밍분류]
• mantis . . . . 1 match
       [도구분류]
• 강희경/메모장 . . . . 1 match
       Zero: 0을 형상화, 알파벳 O와 구분 짓기 위해 선이 그어진 형태(Z가 포함됨).
• 객체지향분석설계 . . . . 1 match
        먼저 Actor를 선정한다. Actor를 잘 선택하면 추후에 유즈케이스를 구분할 때에 도움이 된다.
• 권영기/web crawler . . . . 1 match
        d - 디렉토리 구분
• 논문검색 . . . . 1 match
       ["도구분류"] 이페이지 자체가 도구가 되길래
• 다른 폴더의 인크루드파일 참조 . . . . 1 match
       5. 주의 : ' , ' 로 구분
• 대학원준비 . . . . 1 match
       구분 일시 장소
• 데블스캠프2004/목요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 하세요.''' [[HTML(</center>)]]
• 데블스캠프2005/금요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 적는 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 해줄래요?''' [[HTML(</center>)]]
• 데블스캠프2005/목요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 적는 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 해줄래요?''' [[HTML(</center>)]]
• 데블스캠프2005/수요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 적는 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 해줄래요?''' [[HTML(</center>)]]
• 데블스캠프2005/언어디자인/그까이꺼 . . . . 1 match
       viewer란 프로그램이 있다. 뒤에 출력하고싶은 것을 입력한다. ','로 구분한다.
• 데블스캠프2005/월요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 적는 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 해줄래요?''' [[HTML(</center>)]]
• 데블스캠프2005/화요일후기 . . . . 1 match
       [[HTML(<center>)]]'''후기 적는 방법 : ThreeFs Fact(사실), Feeling(느낌), 교훈(Find)[[BR]] 을 구분해서 명확히 이야기 해줄래요?''' [[HTML(</center>)]]
• 문서구조조정토론 . . . . 1 match
       해당 공동체에 문서구조조정 문화가 충분히 형성되지 않은 상황에서는, NoSmok:ReallyGoodEditor 가 필요합니다. 자신이 쓴 글을 누군가가 문서구조조정을 한 걸 보고는 자신의 글이 더욱 나아졌다고 생각하도록 만들어야 합니다. 간단한 방법으로는 단락구분을 해주고, 중간 중간 굵은글씨체로 제목을 써주고, 항목의 나열은 총알(bullet)을 달아주는 등 방법이 있겠죠. 즉, 원저자의 의도를 바꾸지 않고, 그 의도가 더 잘 드러나도록 -- 따라서, 원저자가 문서구조조정된 자신의 글을 보고 만족할만큼 -- 편집해 주는 것이죠. 이게 잘 되고 어느 정도 공유되는 문화/관습/패턴이 생기기 시작하면, 글의 앞머리나 끝에 요약문을 달아주는 등 점차 적극적인 문서구조조정을 시도해 나갈 수 있겠죠.
• 문제풀이/1회 . . . . 1 match
        1. 다음과 같은 공백으로 구분되는 임의의 숫자 입력이 주어질때 최대, 최소값을 출력하세요.[[BR]](데이터 양은 [Python]과 머신이 처리할수 있는 범위내로 한정)
• 사랑방 . . . . 1 match
       음.. 편한건지 사기인건지 잘 구분이 안간다 -_- --["zennith"]
• 새싹교실/2011/AmazingC . . . . 1 match
        * 식별자란 프로그램을 할때 사용자가 다른 것과 구분할 수 있도록 하는 것
• 새싹교실/2011/學高/1회차 . . . . 1 match
        * SW의 구분: System SW, Application SW
• 새싹교실/2011/쉬운것같지만쉬운반/2011.5.17 . . . . 1 match
        * 배열 나가기 전에 포인터를 나가보았습니다. 변수와 포인터를 비교하며 가르쳐보았습니다. 그러다가 용운이의 질문 덕분에 *(애스터리스크) 연산자가 뜻이 모호하다는 것을 깨닫게 되었습니다. 왜 곱하기랑 주소참소를 구분하지 않았을까요? 의문이군요. 배열하고 포인터는 어차피 다른 개념이라, 기본적인 개념은 포인터를 먼저 가르쳐도 상관없네요. 앞으로는 포인터를 먼저 가르쳐야겠습니다. 왜냐면 맛있는 걸 먼저 먹어야 기분이 좋으니까요? - [박성현]
• 새싹교실/2012/부부동반 . . . . 1 match
       typedef의 쓰임새와 존재 의의?
• 새싹교실/2012/우리반 . . . . 1 match
       (추가 compile이란 High level language , 즉 인간이 구분하기 쉬운 언어로 작성된 프로그램을 Machine language(기계어)로 번역하여 처리하는 작업이라고 생각합니다.-[권도현]
• 새싹교실/2012/절반/중간고사전 . . . . 1 match
        * 변수 선언시 대소문자 구분, 숫자 및 특수문자 사용 못함
• 서버구조 . . . . 1 match
       소스랑 데이터를 구분하여 분류
• 성의과학 . . . . 1 match
        * 나는 이 수업은 2명의 교수에게서 들었다. ( 고로 재수강이었음 :( ) 한 분은 잘 기억이 안나지만 남자 강사였고 다른 한분은 여자 강사였다. 단순히 성으로 구분해서 평가하기는 이상할지도 모르지만 후자의 여자 강사분으로부터 더 좋은 점수를 받을 수 있었고 더 좋은 강의를 들을 수 있었다. 일단 그 이유로는 시청각 자료의 활용과 거침없는 표현들 이었던 것 같다. 시청각 자료로는 성 정체성을 주제로 다루는 영화( 제목은 잘 기억이 나지 않는다. )를 보여줬는데 내용이 지루한 것이 아니어서 수업시간에 집중해서 볼 수 있었다. 무엇보다도 인상적인 부분은 강의때 표현하는 방식이었다. 교과서에 나와있는 내용을 그냥 읽는 것이 아니라 나름대로의 경험(?)에 빗대어서 설명을 해 나갔다. 그리고 남자 학생들의 수보다 여자 학생들의 수가 더 많았다는 것이 신기했다. :) --[구근]
• 스터디그룹패턴언어 . . . . 1 match
       본 패턴언어에는 21가지 패턴이 있다. '정신', '분위기', '역할' 그리고 '맞춤'(Custom)이라고 부르는 네 섹션으로 구분된다. 해당 섹션의 패턴을 공부할 때, 이 언어의 구조를 고려하라. 본 언어의 앞 부분인 '정신' 섹션의 패턴은 스터디 그룹의 핵심 즉, 배움의 정신(spirit of learning)을 정의하는 것을 도와 줄 것이다. 다음 섹션 '분위기', '역할', '맞춤'은 앞선 핵심 패턴과 깊이 얽혀있으며 그것들을 상기시켜줄 것이다.
• 아동언어습득이론 . . . . 1 match
        반박 - 다른 종도 비슷한 시기에 소리 구분 능력 유사
• 아주오래된농담 . . . . 1 match
       행복한 결말은 애초에 바라지도 않았다. 읽는 동안 나에게 질문을 던졌다. 말기암 환자에게 병명을 말해주어야 할까? 모든 여자를 성녀와 나쁜 년으로 구분할 수 있을까? 남자는 가정이 있어도 다른 여자에 대한 유혹을 뿌리칠 수 없을까? 악조건이 사람을 악다구니로 만들까?
• 열린제로페이지 . . . . 1 match
       이 생각에 반대 의견이 무척 거세리라고 생각되지만 정보 공유의 진입 장벽이 될 뿐인 '''제로페이지의 명확한 회원 구분은 불필요하다'''는 주장을 해봅니다. 앞선 네개의 가상 시나리오 중 1-1, 2-1번 시나리오는 실화를 바탕으로 작성했습니다. 1-2, 2-2번 시나리오는 주관적이며 희망적인 방향으로 서술했습니다. 현재의 제로페이지는 연초에 모은 사람들 중 꾸준히 학술적 활동을 하는 사람들만이 제로페이지 회원이 될 수 있는 폐쇄적인 학회입니다. ["열린제로페이지"]로 방향을 잡는다면 학회에서 교류되는 정보의 질과 양을 높일수 있지 않을까요.
• 우리들의행복한시간 . . . . 1 match
       책을 읽고 나서 며칠이 지나, 좋고 나쁨을 구분하는 한 가지 기준은 삶과 죽음이라고 생각했다. 좋으면 삶을 향하고, 나쁘면 죽음을 향한다. 내가 우울하고 슬프면 죽음에 가까워 진 것이고, 내가 즐겁고 행복하면 삶에 가까워 진 것이다. 언젠가 죽지만, 그때까지는 좋은 삶을 마음껏 누리자.
• 위시리스트/130511 . . . . 1 match
        * 프린터는 산다면 HP껄로 사는게 좋습니다. Mac지원을 잘해주거든여. / 암막커튼 설치하는건 왠지 내가 할 수 있을것 같으니 설치 걱정은 하지말고. / 물품신청란에 책과 그외를 구분 했으면 합니다. 헷갈림; - [고한종]
• 이승한/mysql . . . . 1 match
       PHP공부를 위한 mysql 구분 공부.
• 이영호/My라이브러리 . . . . 1 match
       // 성공시 0, 실패시 -1 반환. (socket에서 에러가 났는지 bind에서 에러가 났는지 구분이 힘들겠지만, socket이 할당 되지 않는 경우는 적으므로 bind 에러임.)
• 이영호/미니프로젝트#1 . . . . 1 match
       // 구분하지 않은 파일. 이 파일을 각 파일로 나눈다.
• 정규표현식/스터디/메타문자사용하기 . . . . 1 match
        * 윈도우 시스템에서 폴더의 구분을 역슬래시(\)로 하는 반면에 리눅스 시스템은 슬래시(/)를 사용한다. 따라서 이것을 변경하기 위해 사용할 수 있다.
• 정모 . . . . 1 match
        -> Online (주로 Wiki를 통해 이루어지는) 에서 결정할 내용과 Offline 에서 결정할 내용을 구분하지 못한다.
• 정모/2002.11.13 . . . . 1 match
        DeleteMe) 이날 참석한 인원을 적어주세요. 해당 정보는 차후 회원 구분이 있을때 필요한 자료입니다. --["neocoin"]
• 정모/2002.7.11 . . . . 1 match
        3. 역시 고학번들의 문제지만. 회의 진행중 조언과 자신들의 잡담을 구분하질 않는다. 우리들의 목소리는 어디건 크다.
• 정모/2004.8.9 . . . . 1 match
        *역활에 따른 팀 구분 (ex, 디자인팀, 취재팀..)
• 정모/2011.3.21 . . . . 1 match
        * 저도 컨텐츠(?)별로 구분해서 써보겠습니다.
• 정모/2011.7.25 . . . . 1 match
        * 5.1장에서 회원 등급 조정을 예로 들어 책임을 구분하는 과정이 흥미로웠습니다. 관련 내용은 이번주에 위키에 올리겠습니다.
• 졸업논문/본론 . . . . 1 match
       Django의 설계 철학은 한 마디로 DRY(Don't Repeat Yourself)이다. 확연히 구분할 수있는 데이터는 분리하고, 그렇지 않은 경우 중복을 줄이고 일반화한다. 데이터 뿐 아니라 개발에 있어서도 웹 프로그래밍 전반부와 후반부를 두 번 작업하지 않는다. 즉 웹 애플리케이션 개발자는 SQL을 사용하는 방식이 도메인 언어에 제공하는 프레임워크에 숨어 보이지 않기 때문에 프로그램을 동적으로 쉽게 바뀔 수록 빠르게 개발할 수 있다. 또한 후반부 데이터 모델이 바뀌면 프레임워크에서 전반부에 사용자에게 보이는 부분을 자동으로 바꾸어준다. 이러한 설계 철학을 바탕으로 기민하게 웹 애플리케이션을 개발할 수 있다.
• 중앙도서관 . . . . 1 match
       왜 우리는 학년이나 학부생, 학원생의 임의적 구분에 그렇게 매달리는 것일까. 저학년과 고학년이 한 팀이 되어 뭔가를 함께 하면 여기서 얼마나 많이 배울 수 있을지 사람들은 잘 모른다. 저학년은 고학년의 운신 하나 하나에서 배운다. 그가 키보드를 어떻게 누르고, 버그에 어떻게 대처하는지 등은 글을 통해 알 수 없다. 고학년은 저학년과 함께 일을 하면서 어떻게 팀을 이끌어나갈지, 어떻게 커뮤니케이션을 잘 할지, 내 코드의 가독성이 어떠한지를 배운다.
• 질문의힘 . . . . 1 match
        * 질문 능력 키우기 - 이야기를 들으면서 삼색 볼펜 구분법으로 필기하기
• 책거꾸로읽기 . . . . 1 match
       인도는 인력이 풍부할 뿐 아니라 인구분포 면에서도 젊은 나라이다. 인도는 이미 해마다 수십만 명의 기술인력을 배출하고 있다. 마치 기술자를 기계로 팍팍 찍어내는 인력공장같은 나라가 인도이다.
• 튜터링/2011/어셈블리언어 . . . . 1 match
        * 짝수 홀수 구분부분에서 다들 헤맨듯.
• 페이지이름 . . . . 1 match
        *. ZeroWiki 에서는 '''/''' 으로 페이지 간의 계층을 구분한다.
• 프로그래머의길 . . . . 1 match
       사람은 누구나 어떤 일을 하든 넘어야 할 벽을 만나기 마련이다. 프로그래머역시 여러가지 벽을 만나게 되는데, 필자는 컴퓨터의 벽을 크게 '''이해의 벽'''과 '''창조의 벽''', 그리고 '''마음의 벽'''으로 구분하고자 한다. '''이해의 벽'''은 초보자가 넘어야 하는 벽이고 '''창조의 벽'''은 중급자가, 그리고 마지막 벽인 '''마음의 벽'''은 전문가가 넘어야 하는 벽이다.
• 프로그래밍잔치/Successor . . . . 1 match
       4-5. 세밀한 디자인 - 디자인 변경 생각 없음 3.5 (규모 작음)
• 프로그래밍잔치/둘째날 . . . . 1 match
        * 요구사항을 정리할때. '무엇을 구현할 것인가?' 와 '어떻게 구현할것인가' 를 구분하기.
• 프로그래밍잔치/첫째날후기 . . . . 1 match
        * 오늘 위키의 간단한 룰로서 들고 나온 개인페이지 내 '/' 구분자를 이용하는 계층위키에 대한 사람들의 생각
• 학습된무기력 . . . . 1 match
       셀리그먼은 동물을 대상으로 자신의 학습된 무기력 이론을 실험했다. 그외 동료들은 개에게 충격을 피해 도망치는 법을 가르쳤다. 그들은 셔틀 박스-개가 뛰어 넘을 수 있는 높이의 칸막이로 구분된 상자-에 개를 한마리씩 넣었다. 그리고 조명을 어둡게 해서 개들에게 무슨 일이 일어나리라는 경고를 준 다음 약한 전기 충격을 연속적으로 주었다. 전기 충격은 개들이 칸막이를 뛰어 넘으면 피할 수 있단는 것을 깨달을 때 까지 계속 가했다.
• 헝가리안표기법 . . . . 1 match
       [도구분류]
• 회원자격 . . . . 1 match
        * ["창섭"]:제가 동아리 활동하면서 유령회원을 구분할 때는 반드시 '''적극적이지는 않더라도 연락을 했을 때 망설임 없이 대답할 수 있는 사람'''을 회원이라고 생각했습니다. --창섭

Found 236 matching pages out of 7540 total pages (5000 pages are searched)

You can also click here to search title.